(19) 



J 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



I 



(12) 



(11) BP 1 026 916 A2 

EUROPEAN PATENT APPLICATION 



(43) 


Date of publication: 


(51) lntci7: H04Q 11/04, H04L 12/24, 




09.08.2000 Bulletin 2000/32 




H04J 3/16 


(21) 


Application number: 00300566.7 






(22) 


Date of filing: 26.01.2000 






(84) 


Designated Contracting States: 

AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 

MC NL PT SE 


(72) 


Inventor: Koay, Helena G. 
Windham, New Hampshire (US) 




Designated Extension States: 


(74) 


Representative: 




AL LT LV MK RO SI 




Watts, Christopher Malcolm Kelway, Dr. et al 
Lucent Technologies (UK) Ltd, 


(30) 


Priority: 03.02.1999 US 243269 




5 Mornington Road 

Woodford Green Essex, IG8 OTU (GB) 


(71) 


Applicant: LUCENT TECHNOLOGIES INC. 
Murray Hill, New Jersey 07974-0636 (US) 







(54) Automatic telecommunications linic identification system 



(57) A telecommunications network in accordance 
with the principles of the invention includes one or more 
controllers that automatically determine the physical in- 
terconnectivity between at least two ports adjacently sit- 
uated in different network elements. Each end-point, 
that is, each port, has a unique identification. In an illus- 
trative embodiment, upon the occasion of a network 
modification, such as the addition of a port to the net- 
work, the initiation of a port, or reconfiguration of a link, 



the two ports attached to a communications path to form 
a link exchange their "view" of the link. That is each port 
sends an identification message to the other port. Each 
of these messages includes the identification of the 
sending port and the presumed identification of the re- 
ceiving port. If at first the ports don't agree, the receiving 
port updates its view of the link. This process is repeated 
until both ports agree on the identification of each port 
within the link. 
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Description 

FIELD OF THE INVENTION 

[0001] The invention relates to telecommunications 
networks and, more particularly, to the identification of 
point-to-point links within a telecommunications system. 

BACKGROUND OF THE INVENTION 

[0002] Just as every journey of a thousand miles be- 
gins with a single step, every telecommunications net- 
work begins with a single link. Each link connects two 
telecommunications network elements, from individual 
port to individual port, through a specific transmission 
medium, such as an electrical cable, an optical fiber, a 
radio frequency (RF) channel, or other transmission me- 
dium. Each network element may be linked to one or 
more other network elements through a plurality of 
ports, each of which may include an electrical, optical, 
or RF Interface. In order to properly allocate, or "provi- 
sion", network resources and to react appropriately to 
alarm conditions, one must have an accurate "map" of 
the network, its component links, and their interconnec- 
tion. Unfortunately, the link information is difficult to ob- 
tain, changes all too frequently (through the addition or 
deletion of ports, for example), and is subject to error in 
its discovery. That is, conventional telecommunications 
networks typically rely upon technicians to input link in- 
formation, port-to-port connectivity information, when- 
ever a network element is connected to another network 
element (from one port to another), whenever a network 
element, or a port on the network element, is initiated, 
or whenever the port-to-port connectivity of the network 
is modified in any other way. Not only is the manual entry 
of such link information time consuming, the tedium in- 
volved with such an enterprise very often elicits mis- 
takes from the operating technician. 
[0003] To properly manage a telecommunications 
network, a telecommunications network management 
system typically must be able to identify each link within 
the system. That is, the network management system 
typically accumulates the point-to-point connectivity in- 
formation between the various ports within the system 
to form a network map. The network map portrays the 
"cabling", whether optical, electrical, or otherwise, be- 
tween all the ports within all network elements within the 
system. Such networks typically include a very large 
number of network elements, an even larger number of 
ports, and, as noted above, in conventional telecommu- 
nications networks, each of the links is identified manu- 
ally. The process of identifying each of the network ele- 
ments could be a daunting task. That is, due to the te- 
dium involved, and the consequent propensity for er- 
rors, manually identifying the port-to-port cabling, or link 
identification, or all the links connecting all the network 
elements entails such a great deal of effort as to make 
it practically impossible. Not only must the link identifi- 



cation information be provided to a network manager 
and to each of the network elements at the time of a 
system's initiation, with the addition or deletion of a net- 
work element, or a port associated therewith, the link 

5 identification information within each element in the net- 
work, and/or within a network manager, must also be 
manually updated. Such an approach is not only error- 
prone, but time consuming and, consequently, expen- 
sive. Since it is impracticable for technicians to input and 

10 provision the cabling in this manner, a network manager 
cannot not ascertain the identification and create a map 
of connectivity between all the ports within the network 
manager's domain. 

[0004] A network management system that automat- 
15 ically determines the connectivity path for each link un- 
der its purview would therefore be highly desirable. 

SUMMARY 

20 [0005] A telecommunications network in accordance 
with the principles of the invention Includes one or more 
controllers that automatically determine the physical in- 
terconnectivity between at least two ports adjacently sit- 
uated in different network elements. Each end-point, 

25 that is, each port, has a unique identification. In an illus- 
trative embodiment, upon the occasion of a network 
modification, such as the addition of a port to the net- 
work, the initiation of a port, or reconfiguration of a link, 
each port's associated controller transmits an identifica- 

30 tion message to the port's adjacently neighboring port. 
The identification message includes the transmitting, or 
local, port's identification and the presumed identifica- 
tion of the adjacent receiving, or remote, port's identifi- 
cation. Similarly, the controller associated with the re- 

35 mote port transmits an identification message contain- 
ing the "remote port's view", that is, the local and remote 
port identifications, from the perspective of the remote 
port, to the local port. 

[0006] If the identification messages from the two 

40 neighboring ports agree, that is, if the remote and local 
port identifications of each port are reciprocal, the link 
is identified, in that one or more controllers have deter- 
mined the interconnectivity of the two ports that com- 
prise the link. The controllers retain this link identifica- 

45 tion information until some change in the network con- 
figuration initiates a re-identification. If, however, the 
identification messages from the two neighboring ports 
do not agree, the controller associated with the local port 
will update the "remote" potion of its identification mes- 

50 sage and re-send the message to its neighbor as an ac- 
knowledgement of the updated remote port identifica- 
tion information. Once the link identification is estab- 
lished, this interconnectivity data is maintained until 
such time as a neighboring port sends a link identifica- 

55 tion message, or the port's local identification is modi- 
fied. This exchange of link information is event-driven 
triggered by the creation of a link, by the reestablishment 
of a link connection with an adjacent network element. 
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or by the modification of a port's identification, tine port's 
associated network element's network address, or sym- 
bolic name. In accordance with an illustrative embodi- 
ment of the invention, the link identification includes the 
target identifier and network address of each network 
element and, consequently, the automatic link identifi- 
cation process may be employed to identify the network 
elements within a telecommunications network. 
[0007] Although the invention may employ any of a 
variety of "cabling media", including wire, optical, or RF, 
to connect two ports and thereby form a network link, in 
the illustrative embodiment optical fibers are employed 
in a telecommunications network that may be compati- 
ble with SONET or SDH optical telecommunications 
systems standards. Additionally, although a telecommu- 
nications network in accordance with the principles of 
the invention may employ any of a variety of topologies, 
the illustrative embodiment employs a bidirectional line 
switched ring (BLSR) topology. 

[0008] In an illustrative embodiment, the "discovery" 
of link identification, that is, the determination of port-to- 
port interconnectivity, takes place at the Open Systems 

Interconnection (OSI) data link layer and employs the 
link access procedure for ISDN D-channel (LAPD) pro- 
tocol. The data link layer and other basic concepts of 
the Open Systems Interconnection (OSI) reference 
model are discussed in "Open Systems Networking", 
David M. Piscitello, A. Lyman Chapin, Addison-Wesley 
Publishing Company, Reading Massachusetts, 1993, 
pages 33-62, which are hereby incorporated by refer- 
ence. 

[0009] A network in accordance with the principles of 
the invention may employ a network management sys- 
tem to accumulate the above link identification informa- 
tion for each active link in the network, to thereby create 
a network map. The network management system may 
be a distributed system, in that each element within the 
network, employing its own controller, may develop a 
network map, or network topology Alternatively, in a tel- 
ecommunications system that employs a centralized 
network management system a network management 
system controller may interrogate various network ele- 
ments in order to obtain the link information and then to 
develop the network map. The network map, in turn, 
may be employed by the network management system 
to allocate, or provision, network resources and to prop- 
erly respond to network alarms. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0010] The above and further features, aspects, and 
advantages of the invention will be apparent to those 
skilled in the art from the following detailed description, 
taken together with the accompanying drawings in 
which: 

Figure 1 is a conceptual block diagram of a network 
which automatically identifies the links which com- 



prise the network, in accordance with the principles 
of the invention; 

Figure 2 is a block diagram depicting the contents 
5 of a network identification message that may be em- 

ployed within a network such as that depicted in the 
block diagram of Figure 1 ; 

Figure 3 is a flow chart illustrating the process of 
10 automatically identifying the port-to-port connectiv- 
ity which defines a link within a telecommunications 
network such as that of Figure 1 ; 

Figure 4 is a flow chart that illustrates the process 
15 of automatically producing a network map from link 
identification information such as may be obtained 
in the process depicted in Figure 3; 

Figures 5A through 5C are conceptual block dia- 
20 grams of a BLSR that illustrate the process of auto- 
matic link identification in accordance with the prin- 
ciples of the present invention: 

Figure 6 is a flow chart depicting the use by a node 
25 within a network of link identification information to 
automatically generate a network map; and 

Figures 7A through 7D are conceptual block dia- 
grams which depict the operation of automatically 
30 determining a network topology by various nodes 
within a BLSR. 

DETAILED DESCRIPTION 

35 [0011] A telecommunications network in accordance 
with the principles of the present invention includes one 
or more controllers that automatically determine the 
physical interconnectivity between individual ports with- 
in the telecommunications network. An identification 

40 message, including the identification information related 
to both the sending and receiving ports, is transmitted 
from each port to its adjacent neighbor and, when the 
two ports converge on a view of their interconnectivity, 
that interconnectivity information is stored for each port 

45 within the one or more controllers. By accumulating the 
interconnectivity information for all the links within the 
network, a network management system may produce 
an accurate network map that may be employed for pro- 
visioning network resources and for responding to net- 

50 work alarms. 

[001 2] The conceptual block diagram of Figure 1 illus- 
trates a telecommunications network 1 00 in accordance 
with the principles of the present invention. The network 
includes a plurality of network elements (NEs) intercon- 

55 nected through communications links. Each communi- 
cations link includes a pair of ports and a transmission 
path through which they are connected. The transmis- 
sion paths may be embodied by such media as wire ca- 
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ble, optical fiber, or an RF transmission path, but may 
be referred to hereinafter as a cable or a fiber for the 
sake of convenience. The term network element, or NE, 
will generally be used to refer to any one of a variety of 
telecommunications equipment types, such as a multi- 
plexer, an add/drop multiplexer, a switch, or other piece 
of telecommunications equipment that may act as a 
node within a telecommunications network, Each NE 
typically includes a plurality of ports, each of which may 
be connected through a path, such as an electrical cable 
or an optical fiber, for example, to another port within 
another NE. A network link, essentially, comprises this 
combination of two ports connected through a commu- 
nications path. A network may include one or more such 
network links. Additionally, the network may be viewed 
as a combination of nodes, each of which may be auto- 
matically identified, as described in the provisional Unit- 
ed States patent application filed by the same inventor 
as the current application on December 3, 1 998, having 
a serial number of 60/110724, and entitled, "Automatic 
Node Identification Assignment in Ring Networks", 
which is hereby incorporated by reference in its entirety. 
[0013] In the illustrative embodiment of Figure 1 a plu- 
rality of network elements (NEs) NE-A, NE-B, NE-C, and 
NE-D are interconnected to form a network 100. NE-A 
102 includes four ports. p1,p2, p3, and p4. Each of the 
ports p1, p2, p3 and p4 may comprise electrical or op- 
tical interface circuitry and data may be transmitted or 
received through each of the ports. A network link, over 
which data may be transmitted and received, may be 
formed by attaching a port within one network element 
to a port within another network element through atrans- 
mission path such as an electrical cable or an optical 
fiber. A controller 104 is associated with the NE-A 102 
and may be physically co-located within the same pack- 
age as the NE-A 1 02 or may be located separately, with 
a communications path provided to the NE-A 102. The 
controller 1 04 may take any of a variety of forms, such 
as an embedded controller, dedicated to the associated 
network element, or it may be a controller such as a 
DACScan 2000 ™ as described in "Understanding 
SONET/SDH Standards and Applications, Ming-Chwan 
Chow, pp. 7-1 through 7-40, Andan Publisher, New Jer- 
sey, 1995, which is hereby incorporated by reference. 
[0014] Each network element, NE-B 106, NE-C 108, 
NE-D 110 may include a controller (not shown), and a 
plurality of ports. Ports p5-p8, p9-p12, and p13-p16 are 
respectively contained within network elements NE-B, 
NE-C, and NE-D. Port pi of NE-A is connected through 
transmission path 112 to port p6 of NE-B and port p2 of 
NE-A is connected through transmission path 114 to 
port p5 of NE-B. Similarly ports p8 and p7 of NE-B are 
respectively connected to ports plO and p9 of NE-C 
through transmission paths 116 and 118; ports p11 and 
pi 2 of NE-C are connected to ports pi 4 and p13 of NE- 
D through transmission paths 120 and 122, respective- 
ly; and ports p1 6 and p1 5 of N E-D are respectively con- 
nected to ports p4 and p3 of NE-A through transmission 



paths 124 and 126. In a SONET or SDH network em- 
bodiment of the network 100, each of the transmission 
paths 1 1 2-1 26 might be an optical fiber and the illustrat- 
ed network may be implemented, for example, as a bi- 

5 directional line switched ring (BLSR). SONET networks 
and bidirectional line switched rings are known and are 
discussed, for example, in "Understanding SONET/ 
SDH Standards and Applications, IVIing-Chwan Chow, 
pp. 7-1 through 7-40. 

10 [0015] In accordance with the principles of the present 
invention, the controller 104, under various circum- 
stances including network modifications such as the ad- 
dition of a port to the network, the initiation of a port, or 
the reconfiguration of a link, initiates the transmission of 

15 identification messages from each of the ports to the re- 
spective ports to which they are connected. The identi- 
fication message provides an indication of the transmit- 
ting port's, "view", "perception", or "presumption" of the 
link's configuration. The transmitting port's view of the 

20 link configuration is compared to the receiving port's 
view of the link configuration. As will be described in 
greater detail below, the transmitting and receiving ports 
exchange their views of the link configuration until their 
views converge (not withstanding the somewhat anthro- 

25 pomorphic terminology, there is no implication that the 
ports are, or directly rely upon for their proper opera- 
tions, sentient beings). 

[0016] Specifically, in an illustrative embodiment, the 
identification message include the information set forth 

30 in the illustrative conceptual diagram of Figure 2. In this 
illustrative embodiment, the transmitting port includes 
its own port identity and it's best estimate of the receiv- 
ing port's identity. This estimate may be based upon pre- 
viously received messages from the receiving port or 

35 other sources, or the field may be left "blank" In the il- 
lustrative example, the link identification message 200 
includes local end node 202 and remote end node 204 
information segments. The local end node segment in- 
cludes a version number 206, a target identifier (TID) 

40 208, a port identifier 210, and a network address 212. 
The target identifier is the symbolic name of the port's 
associated network element. Similarly, the remote end 
node information segment 204 includes a version 
number 214, the presumed Tl D 21 6 associated with the 

45 remote port, the presumed port identification 21 8 of the 
remote port, and the network address 220 of the remote 
port's associated network element. As noted above, this 
exchange of link information is event-driven, triggered 
by the creation of a link, by the reestablishment of a link 

50 connection with an adjacent network element, or by the 
modification of a port's identification, or the port's asso- 
ciated network element's network address or symbolic 
name. 

[001 7] The basic link identification process is set forth 
55 in the flow chart of Figure 3. The process begins in step 
300 and proceeds from there to step 302 where the link 

identification information, as set forth in the block dia- 
gram representation of Figure 2, is initialized, with the 
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presumed values for the local 202 and remote 204 end 
node data segments. The remote end node data seg- 
ment 204 could be initialized to "unknown" values, for 
example. The process proceeds from step 302 to step 
304 where an attempt is made to establish a connection 
between the local and remote ports. The attempt is re- 
peated frequently until a connection is established or a 
predetermined period of time has elapsed. In either 
case, the process proceeds from step 304 to step 306, 
where it is determined whether the connection to the ad- 
jacent port has been established. If the connection has 
not been made, the process proceeds to step 308, 
where less frequent attempts to connect to the adjacent 
port are made. The association may be made at a data 
link layer and, in an illustrative OSI embodiment, the 
connection is made through an OSI data link layer em- 
ploying the LAPD protocol. More specifically, the con- 
nection employs the AITS service of the LAPD protocol, 
which insures reliable communications for this critical 
step. From step 308 the process proceeds to step 310 
where it is determined whether a connection to the ad- 
jacent port has been established. If no connection has 
been made, the process returns to step 308. If the con- 
nection has been established the process proceeds, as 
it would from step 306 when a connection is established, 
to step 312, where the local port transmits its link iden- 
tification information, e.g., the link identification mes- 
sage 200, to the remote port. 

[0018] In step 314 a test is performed to determine 
whether the transmission to the remote port has failed, 
has been successful, or the connection has been termi- 
nated. If the connection has been terminated, the proc- 
ess returns to step 304, and from there as previously 
described. If the transmission has failed, the process re- 
turns to step 312 to re-send the link identification mes- 
sage. If the transmission was successful, the process 
proceeds from step 31 4 to step 31 6, where the local port 
awaits the reception of a link identification message 
from the remote port. From step 316 the process pro- 
ceeds to step 318 where it is determined whether the 
remote port's link identification message has arrived or, 
the connection to the remote port has been terminated. 
If the connection has been terminated the process pro- 
ceeds to step 304, and from there as previously de- 
scribed. If it is determined that the remote port's link 
identification message has been received, the process 
proceeds to step 320 where the remote and local link 
identification messages are compared, and, if they are 
not the same, the process proceeds to step 321 , where 
the local port updates its link identification information. 
From step 321 , the process returns to step 31 2 and pro- 
ceeds from there as previously described. On the other 
hand, if the local and remote link identification messag- 
es are the same, the process proceeds from step 320 
to step 322. 

[0019] In step 322 a state is entered whereby the 

process essentially idles, awaiting an event, such as an 
update in the remote port's identification, modifications 



to the local port's identification, or the termination of the 
connection to the remote port. Other processes may be 
taking place in parallel at the same time, on the same 
controller or network management system. When such 

5 an event occurs, the process proceeds from step 322 to 
step 324 where it is determined whether the remote 
port's link identification message has been received 
and, if it has, the process returns to step 320 and pro- 
ceeds from there as previously described. If the remote 

10 port's link identification message was not received, the 
process proceeds from step 324 to step 326 where it is 
determined whether local port identification information 
has been changed. If local port identification information 
has been modified, the process returns to step 321 and 

15 from there as previously described. If local identification 
information has not been updated the process proceeds 
to step 328, where it is determined whether the link to 
the remote port has been terminated and, if so, the proc- 
ess returns to step 304 and, from there as previously 

20 described. If the link to the remote port has not been 
terminated the process returns to step 322 and from 
there as previously described. 

[0020] Once the link identification has been estab- 
lished in this manner, the link identification information 

25 may be employed to form, with a network management 
system, for example, a network map. The network map 
could then be used to provision the bandwidth capacity 
of the various links within the network or to respond to 
network alarms by correlating network alarms and iso- 

30 lating failures. Additionally, the system could respond by 
re-routing data around a failed link, for example. The 
flow chart of Figure 4 sets illustrates the basic steps in- 
volved in creating a network map based upon the link 
identification information established according to the 

35 process described in the discussion related to the flow 
chart of Figure 3. Once the map is established, the re- 
sources referenced by the map may be allocated and 
modifications to the link information may be reflected in 
the map. 

40 [0021] The process of producing a network map be- 
gins in step 400 and proceeds from there to step 402 
where link identification information, such as that estab- 
lished in the process described in relation to the flow 
chart of Figure 3, is gathered. From step 402 the process 
45 proceeds to step 404, where it is determined whether 
link identification information for all the links in the net- 
work has been gathered and, if not, the process returns 
to step 402. If link identification information for all the 
links within the network has been gathered, the process 
50 proceeds to step 406, where the network map is updat- 
ed. This process involves organizing the link identifica- 
tion information gathered in step 402 into coherent map 
which depicts the point to point connection of each port 
in each network element within the network. The updat- 
es ing process may involve the revision of an existing map, 
or may be the initial creation of a network map. A net- 
work management system could develop a network 
map by accessing a single network element and tracing 
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all the links with which that network element is associ- 
ated to the opposite ends of the links. The links associ- 
ated with network elements that incorporate these op- 
posite ends may then be traced, and so on, until all links 
within the network are accounted for and included in the 
network map. 

[0022] From step 406 the process proceeds to step 
408 where the network map created in step 406, the 
map which relies upon link identification information ob- 
tained according to the process described in relation to 
the discussion of Figure 3, is employed to allocate the 
available network resources for the transmission of in- 
formation throughout the network. From step 408 the 
process proceeds to step 41 0 where the process awaits 
a link event that would affect the network map or provi- 
sioning. Should such an event occur, the process re- 
turns to step 402 and from there as previously de- 
scribed. Such link events might include the addition or 
deletion of a link, the modification of a link identification 
or an alarm that indicates the failure of a specific link, 
for example. In this manner, the network may respond 
to any such link event to identify links, collect link identity 
information, update the network map and provision net- 
work resources accordingly. The process may idle in 
step 410 awaiting such an event or when the network 
manager is upgraded, for example, the process may 
proceed to end in step 412. 

[0023] The example of Figures 5A through 5C sets 
forth in greater detail an illustrative embodiment in ac- 
cordance with the principles of the present invention of 
a method of producing a network map A SONET bidi- 
rectional line switched ring (BLSR)is used in the exam- 
ple of Figures 5A through 5C, but the inventive method 
is not restricted to SONET or BLSR topologies. The il- 
lustrative network mapping is an autonomous topology 
determination that relies upon information regarding the 
interconnectivity between adjacent nodes, or network 
elements, in a telecommunications network. This inter- 
connectivity information, that is, the identification of 
which port, and, consequently, which node, is connect- 
ed to each port within a given network element, or node, 
is supplied as by the apparatus and process described 
in the discussion related to Figures 1 through 4. In ad- 
dition to the previously described link modification 
events that may trigger the updating of a network map, 
a timer may be set so that the network map may be up- 
dated at regular intervals. 

[0024] A BLSR network including four network ele- 
ments, nodes A, B, C, and D is illustrated in the concep- 
tual block diagram of Figure 5A. Port p6 of Node A is 
connected to port p4 of node B, port p3 of node B is 
connected to port p4 of Node C, port p3 of Node C is 
connected to port p2 of Node D, and port pi of Node D 
is connected to port p5 of Node A. A port ID could be a 
combination of physical identifiers that correspond to 
the bay, shelf, slot, and port numbers for a given port. 
The network address, for example, an OS! network en- 
tity title (NET) or TCP/IP address, name (TID) and sys- 



tem identification (System Id) for each network element 
is listed next to the respective network element. The 
Systemid value is actually a component of the network 
address. The network address, name, and system iden- 

5 tification for nodes A-D are, respectively, net1, net2, 
net3, and net4, node A, node B, node C, and node D, 
123456 756283, 232323, and 325721 . As the link iden- 
tification information exchange process begins, each 
port of each node transmits the above link identification 

10 information, as previously described, employing the OSI 
data link layer and the LAPD protocol in this illustrative 
embodiment. 

[0025] This exchange of information is illustrated in 
greater detail in the conceptual block diagram of Figure 

15 5B within which the arrows 500, 502, 504, and 506 re- 
spectively indicate the transmission of link identification 
information from node A to node B, node B to node C, 
node C to node D, and node D to node A. Similarly, ar- 
rows 508, 510, 512, and 514 respectively indicate the 

20 transmission of link identification information from node 
A to node D, node D to node C, node C to node B, and 
node B to node A. Upon completion of this link identifi- 
cation information exchange, each node within the net- 
work has acquired the link identity information for each 

25 link, including the local and remote port identification, 
as well as the network address (NET), name (TID) and 
system identification (Systemid) for each adjacent net- 
work element. 

[0026] The information thus exchanged is summa- 

30 rized in the tables associated with the nodes A-D in the 
conceptual block diagram of Figure 5C. For example, 
the table associated with node A indicates that port p5 
(a local port) is connected to remote port pi associated 
with a remote network address, NET, of net4 and remote 

35 name, TID, of node D. Similarly, local port p6 is connect- 
ed to a remote port p4 that has a network address, NET, 
net2 and name, TID, of node B. 
[0027] The above link identification information may 
be employed to determine the network topology, for ex- 

40 ample, as described in the discussion related to Figures 
6 through 7D. The illustrative process is decentralized, 
in that the process is executed independently at each 
network element, or node. The topology determination 
process distributes the link identification information, 

45 gathered as described in the discussion related to Fig- 
ures 1 through 4, from node to node, each direction 
around the ring, with each node appending its own link 
identification information and passing the information 
along. 

50 [0028] The flow chart of Figure 6 depicts, in general 
terms, the process each node within the ring undergoes 

to determine the network topology. The process begins 
in step 600 and proceeds from there to step 602 where 
the node retrieves the previously obtained link identifi- 
es cation information for each of its associated links. Al- 
though the network illustrated in the exemplary embod- 
iments related to figures 5A through 7D have only two 
links associated with each node, each node may have 
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several links, as in a multiply nested ring. From step 602 
the process proceeds to step 604 where the node es- 
tablishes an OS I association with both its East and West 
neighbors. 

[0029] After establishing the OSI associations, the 
process proceeds to step 606 where the node sends 
network information, including the local NET, the local 
East or West label associated with the transmitting port, 
and the link identification information, to its East and 
West neighbors. From step 606 the process proceeds 
to step 608 where the originating node waits to receive 
network information from the neighbors to which it has 
sent its own network information. When network infor- 
mation is received from another node the process pro- 
ceeds to step 61 0 where the node determines whether 
it has received appended messages from its East and 
West neighbors. If it has not received messages from 
both directions, the process returns to step 608, where 
the node awaits the receipt of an appended message 
from the remaining neighbor node. Rather than deter- 
mining whether it has received messages from both di- 
rections, a non-originating node would append its own 
data to a received message and pass the appended 
message to the opposite port. That is, if a non-originat- 
ing node receives a message at its East port, it will add 
its information to the message, then transmit the mes- 
sage to its western neighbor. If the node (originating) 
determines in step 610 that it has received messages 
from both its neighbors, the process proceeds to step 
612 where the gathered information is examined to de- 
termine the network topology and the resulting topology 
is examined to determine whether it is a valid topology. 
[0030] If the topology is not valid, the process pro- 
ceeds to step 613 for error processing, which may in- 
clude setting error flags and a renewed attempt at de- 
termining the network topology. From step 613 the proc- 
ess proceeds to end in step 618. If, in step 612, it is 
determined that the network topology is valid, the proc- 
ess proceeds to step 614 where it is determined whether 
any Tl Ds (network element names) have been duplicat- 
ed. If TIDs have been duplicated in the information ex- 
change, the process proceeds to the error processing 
of step 613, and from there as before. If no TIDs have 
been duplicated, the process proceeds to step 616 
where it is determined whether any NETs (network ele- 
ment addresses) were duplicated in the information ex- 
change. If any NETs have been duplicated; the process 
proceeds to the error processing of step 613 and from 
there as previously described. If no duplicate NETs are 
uncovered, the process proceeds from step 616 to end 
in step 618. 

[0031] The conceptual block diagrams of Figures 7A 
through 7D illustrate the process of determining a net- 
work topology in an exemplary SONET BLSR network. 
The process begins in Figure 7A when node D, after es- 
tablishing OSI associations with its East and West 
neighbors, transmits network information, to node A, us- 
ing the East port of node D, that is port pi and transmits 



network information to node C, using the West port of 
node D, port p2. As noted above, the network informa- 
tion transmitted to nodes A and C includes node D's NET 
information, an indication of whether the transmitting 

5 port is an East or West port, and the link identification 
information. The information transmitted from Node D 
to node A, therefore, includes net4/E/nodeD/p1/nodeA/ 
p5, respectively the local NET, the local East or West 
label of the port, the local TID, local port ID, the remote 

10 TID, and the remote port ID. Similarly, the information 
transmitted from node D to node C includes net4/W/nod- 
eD/p2/nodeC/p3, respectively the local NET, the local 
East or West label of the port, the local TID, local port 
ID, the remote TID, and the remote port ID. 

15 [0032] Figure 7B illustrates the further step of the net- 
work topology determination whereby the nodes which 
received network information from node D proceed to 
append their information and transmitted the concate- 
nated network identification information to the node 

20 which lies opposite the port at which they received the 
network identification information. For example, since 
Node A has received a message at its west port port p5, 
from node D, after appending its own identification in- 
formation to the message, node A transmits the mes- 

25 sage from its opposing. East, port to node B Similarly, 
since node C has received a message at its west port, 
port p3, from node D, after appending its own identifica- 
tion information to the message, node C transmits the 
message from its opposing. East, port to node B. 

30 [0033] In Figure 7C the process proceeds to the point 
where node B has received messages from both direc- 
tions, appended its own identification information to 
those messages, and transmitted the concatenated 
messages through its opposing ports. For example, the 

35 message sent from node B to node C would include the 
node D port pi and node A p6 information along with 
the node B p3 information. 

[0034] When the originating node, node D, receives 

return messages from both directions, as depicted in 

40 Figure 7D, node D has acomplete ring map of the BLSR, 
including ring node connectivity at the port interface, as 
well as the TIDs and NETs of all nodes on the ring. The 
network map, or topology, thus discovered may be em- 
ployed to adjust to alarm conditions. For example, 

45 should an alarm indicate that the link including port p5 
of node A and port pi of node D has failed, communi- 
cations may be rerouted between node D and node A 
by transmission from node A to node B, from node B to 
node C, and from node C to node D, rather than directly 

50 from node A to node D. 

[0035] The foregoing description of specific embodi- 
ments of the invention has been presented for the pur- 
poses of illustration and description. It is not intended to 
be exhaustive or to limit the invention to the precise 

55 forms disclosed, and many modifications and variations 
are possible in light of the above teachings. The embod- 
iments were chosen and described to best explain the 
principles of the invention and its practical application. 
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and to thereby enable others skilled in the art to best 
utilize the invention It is intended that the scope of the 
invention be limited only by the claims appended hereto. 



Claims 

1. A telecommunications network, comprising: 

a plurality of network ports, 

a communications path connecting two net- 
work ports, and 

an automatic link identifier configured to trans- 
mit a port identification message from each of 
the connected ports to the other connected port 
through the communications path. 

2. The network of claim 1 wherein the automatic link 
identifier is configured for the port identification 
messages from each of the ports to converge on an 
agreed upon identification for each said port. 

3. The network of claim 1 further comprising a control- 
ler that is responsive to network port modifications 
by initiating the transmission of the port identifica- 
tion messages 

4. The network of claim 1 wherein the communications 
path is an optical communications path. 

5. The network of claim 4 further comprising at least 
one network element that includes one of said ports 
and said port is a SONET port. 

6. The network of claim 4 further comprising at least 
one network element that includes one of said ports 
and said port is a SDH port. 

7. The network of claim 3 wherein the controller is con- 
figured to identify a link within the network by deter- 
mining the identities of the two ports connected by 
a communications path to form a network link. 

8. The network of claim 7 wherein the controller is con- 
figured to develop a network map by accumulating 
the link identities of a plurality of links within the net- 
work. 

9. The network of claim 8 further comprising an alarm 

processing system responsive to network alarms by 
re-routing communications through the network, 
said alarm processing system also responsive to 
the common identification of each port within the 
network. 

10. The network of claim 8 further comprising a provi- 



sioning system configured to allocate telecommu- 
nications bandwidth in accordance with said net- 
work mapping. 

5 11. In a telecommunications network including a plural- 
ity of ports connected through communication 
paths, each combination of communications path 
and connected network ports forming a network 
link, a method of determining a unique identity pair- 

10 ing ports within a link, comprising the steps of: 

(A) transmitting a port identification message 
from a first port at one end of a network com- 
munications path to a second port connected 
15 at the opposite end of the communications 

path, said port identification message including 
information regarding the first port's perception 
of the network link. 

20 (B) receiving a second port identification mes- 

sage from the second port, said second port 
identification message including information re- 
garding the second port s perception of the net- 
work link, 

25 

(C) comparing the two ports' perceptions of the 
network link. 

1 2. The method of claim 1 1 wherein step (A) comprises 
30 the step of : 

(A1 ) forming a logical data link connection be- 
tween neighboring ports. 

1 3. The method of claim 1 1 wherein step (A) comprises 
35 the step of: 

(A2) transmitting port identity information over 
the logical data link connection. 

14. The method of claim 1 1 wherein step (A) comprises 
40 the step of: 

(A3) employing LAPD protocol for transmit- 
ting port identity information. 

15. The method of claim 11 further comprising the step 
45 of: 

(D) storing the two ports' perception of the net- 
work link if the comparison of step C reveals that 
the two ports perceptions of the network link is the 
same. 

50 

16. The method of claim 15 further comprising the step 
of: 

the first port updating its perception of the link 
to agree with the perception received from the sec- 
55 ond port. 

17. The method of claim 16 further comprising the step 
of: 
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(F) returning to step (A). 

18. In a telecommunications network including a plural- 
ity of ports connected through communication 
paths, each combination of communications path 5 
and connected network ports forming a network 
link, a method of creating a telecommunications 
network map comprising the steps of: 

(G) determining a unique identity for each port io 
within a link using the following steps: 

(H) transmitting a port identification message 
from a first port at one end of a network com- 
munications path to a second port connected ^5 
at the opposite end of the communications 
path, said port identification message including 
information regarding the first port's perception 

of the network link, 

20 

(I) receiving a second port identification mes- 
sage from the second port, said second port 

identification message including information re- 
garding the second port's perception of the net- 
work link, 25 

(J) comparing the two ports' perceptions of the 
network link, 

(K) associating each of the ports within the net- so 
work whose unique identities have been deter- 
mined in steps (G) through (H) with the network 
element in which it resides, and 



24. The method of claim 11 wherein the transmitting 
port is a SDH port. 

25. The method of claim 18 wherein the network is a 

bidirectional line switched ring and an initiating net- 
work element transmits identification messages 
from its east and west ports. 

26. The method of claim 25 wherein each network ele- 
ment in the ring other than the initiating network el- 
ement: 

receives an identification message at a first, 
east or west port; 

appends its own identification information to 
the identification message; and 

passes the updated message from its opposite, 
west or east port. 

27. The method of claim 26 wherein the initiating net- 
work element: 

accumulates the network information received 
from both its east and west ports; and 

forms a network map based upon that accumu- 
lated information. 



(L) accumulating the link identity information to 35 
form a network interconnectivity map. 

19. The method of claim 1 8 further comprising the step 
of: 

(M) provisioning telecommunications paths 40 
between network elements according to the net- 
work map formed in step (L). 

20. The method of claim 1 9 further comprising the step 

of: 45 

(N) adjusting telecommunications bandwidth 
flow through the network in response to the activa- 
tion of a network system alarm. 

21. The method of claim 12 wherein the logical data link 50 
connection is a LAPD AITS service. 



22. The method of claim 11 wherein the path is an op- 
tical telecommunications path. 

23. The method of claim 11 wherein the transmitting 
port is a SONET port. 
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